🧹 Hide custom Hyku Commons workflow #994
Conversation
This commit will hide the custom Hyku Commons workflow from the admin workflow form. This is a temporary measure to ensure that the option is not going to show up in the admin interface to reduce confusion. The long-term fix will be to create a script and delete the custom workflow from the database from each tenant, however it was warned that working with Siptiy::Workflow might be a little tricky. Ref: - #448
There was a problem hiding this comment.
I don't think we want to override the view and leave the data behind. Doing this half-way adds more complication for the knapsack work. So unless someone disagrees, I believe we should leave this until we can do the task fully.
I think we want to document the data migrations needed: Before deleting the workflow, you need to update Sipity::Entity to use the workflow_id that is being substituted for the one being deleted. This is a database table, so the command to update would be fairly simple... something like Sipity::Entity.where(workflow_id: 3).update_all(workflow_id: 1)
When you delete a workflow, you need to delete all of the child records that are unused. See https://github.com/samvera/hyrax/blob/main/artifacts/entity-relationship-diagram.pdf for the data diagram. The workflow definitions are the black tables. Workflow_id would be in the WorkflowRole, WorkflowState, and WorkflowAction tables. Lower level entries could also be affected as long as the entries aren't used with a different workflow. It's not ideal to have any orphaned definition records.
Story
This commit will hide the custom Hyku Commons workflow from the admin workflow form. This is a temporary measure to ensure that the option is not going to show up in the admin interface to reduce confusion. The long-term fix will be to create a script and delete the custom workflow from the database from each tenant, however it was warned that working with Siptiy::Workflow might be a little tricky.
Ref:
Screenshots / Video